1. Field of the Invention
The invention relates to computer systems, and more particularly to the access of recovery logs in a database system.
2. Background
The occurrence of a hardware, software, network, process, or system failures in a database system could result in corruption, inconsistencies, or errors to database data. To prevent such problems from occurring, many database systems implement recovery mechanisms capable of restoring the database to a consistent and error-free state if such failures are detected. Recovery mechanisms typically utilize one or more recovery logs or recovery files (collectively referred to herein as “recovery logs”) to perform the recovery process. Recovery logs record information about the database data, such as changes to the database data or the state of database data as of a certain point in time.
A commonly implemented recovery log is a “redo log.” Redo logs contain records of changes made to objects in a database system, regardless of whether the changes are committed or uncommitted. For example, the redo log may record a stream of data containing the identity of each data item that changed in the database, as well as the precise change that is made to the data item. If a failure occurs, the redo log can be used during the recovery process to “redo” any changes that occurred prior to the failure, to place the database in a consistent state as of a specific point in time.
Another type of recovery log is the “undo log.” Undo logs store information that can be used to undo or roll back a change that occurs in the database. For example, an undo log may record a stream of data containing the identity of each data item that is changed in the database, as well as the old value of the data item prior to the change. If a failure occurs, the undo log information is used to roll the database back to a consistent state as of a specific point in time (e.g., by removing all uncommitted data from the database).
Since recovery logs effectively become a historical repository for all changes made to the database data, the information recorded in the recovery logs can be used for many purposes beyond just system recovery operations. For example, the change log information can be used for auditing purposes. Consider if it is desired to audit financial transactions made against financial data stored in a database. Since every change to the financial data is stored in the recovery logs, detailed auditing of changes can be made to any data item at any point in time covered by the recovery logs information.
Statistical analysis of the recovery log information can also be used for capacity planning, system tuning, and system sizing purposes. Moreover, change information in the recovery logs can be used to reconstruct database statements (e.g., structured query language “SQL” statements) that implement changes to the database.
In addition, recovery log information allows any logical corruption in the database to be precisely pinpointed. This is helpful in performing time-based or change-based recovery, allowing the database to be restored to a consistent state before the exact moment that a failure occurs. Moreover, precise identification of logical corruption facilitates debugging of complex applications.
Information in recovery logs are normally stored in a proprietary and/or encoded format. To provide access to this data, the data format of the recovery logs is published by the developer of the database system. If it is desired to access the recovery log data, specialized utilities can be developed to retrieve information from the recovery logs. To properly access this information, the specialized utilities employ the published format information of the recovery logs to properly interpret any data retrieved from the logs.
One drawback to this approach is that if the format of the recovery logs is changed by the developer of the database system, then every utility based upon the previously published formats becomes obsolete or inoperative. Every time the recovery log format changes, significant expenses and resources must be expended to rework existing utilities to accommodate the new recovery log formats. This creates significant disincentives for a developer to change recovery log formats after they have been published. This becomes a difficult situation for many database developers. If the format of recovery logs are not published, then users do not have effective access to the information contained in recovery logs. However, if the recovery log formats are published, then constraints may be imposed upon the developer's ability to make changes to the recovery log formats.
Therefore, there is a need for an improved method and mechanism for managing access to information contained in database recovery logs. Thus, an object of the invention is to provide a method and mechanism for allowing users to access information stored in recovery logs, yet provide the user adequate insulation from potential changes in recovery log formats that may be imposed by database developers.